home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000175_icon-group-sender _Thu Apr 23 08:55:57 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id IAA28064
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Thu, 23 Apr 1998 08:55:57 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA04922; Thu, 23 Apr 1998 08:55:54 -0700
  7. Message-Id: <353E1EF9.21F9@gte.net>
  8. Date: Wed, 22 Apr 1998 11:46:49 -0500
  9. From: MJE <evans@gte.net>
  10. Reply-To: evans@gte.net
  11. Organization: None
  12. X-Mailer: Mozilla 3.01 (Win95; I)
  13. Mime-Version: 1.0
  14. To: jeffery@cs.utsa.edu
  15. Cc: icon-group@optima.CS.Arizona.EDU, evans@gte.net
  16. Subject: Re: Is this language dead?
  17. References: <6gir3d$d0d@bgtnsc02.worldnet.att.net>, <slrn6j2hok.6li.davecook@mozart.cts.com>, <6hhqi6$2p9@bgtnsc01.worldnet.att.net> <6hjj4m$inc@ringer.cs.utsa.edu>
  18. Content-Type: text/plain; charset=us-ascii
  19. Content-Transfer-Encoding: 7bit
  20. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  21. Status: RO
  22. Content-Length: 2173
  23.  
  24. >
  25. > Sorry, you should use C if you need the full Win32 API.  It is gigantic,
  26. > ugly, and something we wouldn't want in the language.  A Windows loadfunc()
  27. > may get implemented and do what you want someday; I just need a DLL guru
  28. > to come in and do it for us.
  29.  
  30.  
  31. Three comments:
  32.  
  33.  
  34. (1) Ugly barely begins to describe the Win32 API.  What a royal mess it
  35. is.  I recently told a colleague that I was not happy with my C++ design
  36. because it had to be tacked on to the side of our C++ framework. 
  37. "Well," he said, "the Windows SDK is tacked onto the side of the Windows
  38. SDK."
  39.  
  40.  
  41. (2) Stop talking about DLL's!  You don't want to use DLL's as such, but
  42. Component Object Model (COM) interfaces.  COM objects solve all the
  43. problems associated with DLL's.  Good online articles are at
  44.  
  45.     http://www.microsoft.com/oledev/olecom/aboutole.htm
  46.     http://www.microsoft.com/oledev/olecom/com_modl.htm
  47.  
  48. and an excellent, basic book on the topic is described at
  49.  
  50.     http://mspress.microsoft.com/prod/books/19.htm
  51.  
  52. This book is very well-written and a good starting point for the
  53. uninitiated.  It does not bog you down with the full weight of OLE2 or
  54. ActiveX or ATL; it just describes COM.  It holds you by the hand until
  55. you understand.
  56.  
  57. Under COM, the main program does not need to know which physical file
  58. holds the COM code with which it wants to link at run time.  The
  59. operating system handles those details invisibly.
  60.  
  61. The interesting aspect of COM is that it is already being ported to Unix
  62. by Software AG and has already been ported to the Mac.  COM is not
  63. inherently a Windows-only API.  Finally, Microsoft has done something
  64. right.  COM also maps closely to C++ although it is a
  65. language-independent standard.
  66.  
  67.  
  68. (3) A different way to approach the problem is to make Icon itself into
  69. a COM object that is callable from external C++ code.  I don't have many
  70. concrete ideas on how to do it.  You could have the interpreter swallow
  71. a whole Icon program file as one COM interface, or have it accept
  72. individual command lines as another.
  73.  
  74. I like the idea of having a COM Icon library that provides Icon-specific
  75. services to external code, such as string scanning.
  76.  
  77.  
  78. Best regards,
  79.  
  80. Mark Evans
  81.  
  82.